前面文章討論很多關於可觀測性的觀念與工具，最重要的是在實務面上我們如何將理論實際應用，來解決真實世界上開發團隊所遇到的問題

透過可觀測性，我們如何具體幫助線上問題釐清呢？

問題排除流程

如果你是開發或是運維團隊人員，當線上系統或負責應用程式遇到問題時，會做哪些事情來協助定位問題，上圖是當問題發生到被修復可能的流程

• 警報 (Alert) : 當系統監控偵測到異常或是特定指標 (Metrics) 超過預定的閥值或水位時，系統會產生告警警報，對於 RD 及團隊來說，這是首先被告知問題的方式。
• 儀錶板 (Dashboard) : 收到警報後，RD 可能會先查看 Dashboard 了解異常背後的數據。Dashboard 提供即時的數據視覺化，幫助 RD 快速定位問題範圍和影響程度。
• 查詢 (Adhoc Query) : 若 Dashboard 所提供的資訊不足，或是為了要更精準確定問題原因，RD 會使用 adhoc Query 進一步的來查找特定時間的數據資料來確認問題。
• 日誌 (Log Aggregation) : 確認問題範圍後，RD 會查找相關的系統或是應用程式 Log，Log 中可能包含更明確的應用程式執行資訊，或是問題的詳細描述與錯誤訊息，幫助 RD 更有機會找到問題的具體原因
• 分散式追蹤 (Distributed Tracing) : 如果應用程式架構是分散式系統，RD 會使用分散式工具來找特定請求式如何在多個服務間流動過程，有助於找到性能瓶頸或可能失敗的原因。
• 修復 (Fix) : 一旦問題被定位，就有機會定位問題並進行緊急修復的動作。可能解決方式式調整配置設定檔、修正錯誤的程式或是重新啟動服務(重開治百病)

透過上述的流程與步驟之後了解到每個步驟的細節，接著整理各個步驟其主要目的如下

以上流程可以看到可觀測性中強調的信號 metics、logging、trace 在問題定位上扮演重要的角色，可以幫助問題發生當下縮短系統異常的恢復時間 (MTTR)，也可以看出前面文章提到的監控與可觀測性是相符相乘的，無法取代彼此。

Grafana 生態系提供了一系列強大的工具，可以輔助開發團隊預防、定位及後續的分析跟優化，以下是針對各階段的工具說明

• 事前預防

  • 預警系統 : 使用 Grafana Alter，基於當前指標的警報外，也可以設定基於數據趨勢的警報，例如，當系統的記憶體使用率持續上升時，可以提前通知，即使當前使用率還在正常範圍內。
  • 動態儀錶板 : Grafana Dashboard，建立動態儀錶板，展示系統的各種指標，從而實時了解系統的健康狀態
  • 持續性能測試: 使用 k6 定期執行性能測試，確保不會隨時掛掉
  • 系統健康檢查: 定期的系統健康檢查，識別任何潛在的問題或不足之處。

• 事中處理

  • 使用可觀測性相關工具像是 Grafana、Loki、Tempo 工具整合，快速定位問題與盤查

• 事後分析

  • 數據視覺化: 利用工具進行數據分析，找出可能的隱患或問題根源。
  • 使用 Grafana Pyrscope 進行線上的應用程式信能分析。

不只是工具

透過事前預防、事中處理與事後分析，加上結合 Grafana 可觀測性的工具，可以更有效的處理管理與加速問題處理速度。但實務面上除了工具的使用之外，更重要的是 團隊成員的合作 與 清晰的 SOP 機制 也不能忽視。

不同人代表有各種不同的工作方式與思維。舉例來說在寫程式時 Junior 與資深的開發人員對於程式寫法不同，為了確保程式的可讀性，就會需要定義制定統一規範並在 Code Review 落實，才有機會大家在看 Code 跟閱讀時更加輕鬆。

同理，在緊急問題處理時需要定義清楚異常事件的 SOP，以便問題發生時知道該採取哪一些步驟，包含該使用那些工具分析與定位、定時回報的機制事後事故報告(RCA)內容寫法，減少混亂並確保團隊成員都可以依照相同方式進行操作，在新成員加入時也不會因為認知落差而影響到處理時效性，提高其處理問題的效率。

補充：在處理線上問題時，核心目的是先止血，不是急於尋找根本原因。這也是為什麼我們需要清晰的流程和工具來協助我們在問題發生時快速應對，而不是盲目地尋找問題的原因 (思路 : 止血、暫時解、根本解)。

下一篇將介紹 Grafana 提供 Grafana Incident Response & Management (IRM) 解決方案，如果有任何疑問或想法，歡迎留言提出討論 !

參考連結

Beyond the 3 Pillars of Observability

面向故障处理的可观测性体系建设